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Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (1999). All Rights Reserved. 
IESG Note 


This document is the output of a vendor consortium, and is not the 
output of an IETF Working Group. Implementors of this specification 
are warned that this data model is heavily biased toward conventions 
used in the United States, and the English language. As such it is 
unlikely to be suitable for international or multilingual use in the 
global Internet. 


Abstract 


Customers are frequently required to enter substantial amounts of 
information at an Internet merchant site in order to complete a 
purchase or other transaction, especially the first time they go 
there. A standard set of information fields is defined as the first 
version of an Electronic Commerce Modeling Language (ECML) so that 
this task can be more easily automated, for example by wallet 
software that could fill in fields. Even for the manual data entry 
case, customers will be less confused by varying merchant sites if a 
substantial number adopt these standard fields. 
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1. Introduction 
1.1 Background 


Today, numerous merchants are successfully conducting business on the 
Internet using HTML-based forms. The data formats used in these forms 
varies considerably from one merchant to another. End-users find the 
diversity confusing and the process of manually filling in these 


forms to be tedious. The result is that many merchant forms, 
reportedly around two thirds, are abandoned during the fill in 
process. 


Software tools called electronic wallets can help this situation. A 
digital wallet is an application or service that assists consumers in 
conducting online transactions by allowing them to store billing, 
shipping, payment, and preference information and to use this 
information to automatically complete merchant interactions. This 
greatly simplifies the check-out process and minimizes the need for a 
consumer to complete a merchant’s form every time. Digital wallets 
that fill forms have been successfully built into browsers, as helper 
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applications to browsers, as stand-alone applications, as browser 
plug-ins, and as server-based applications. But the proliferation of 
electronic wallets has been hampered by the lack of standards. 


ECML (Electronic Commerce Modeling Language, <www.ecml.org>) Version 
1 provides a set of simple guidelines for web merchants that will 
enable electronic wallets from multiple vendors to fill in their web 
forms. The end-result is that more consumers will find shopping on 
the web to be easy and compelling. 


The set of fields documented herein was developed by the 
Wallet/Merchant Standards Alliance (www.ecml.org) which now includes, 
in alphabetic order, the following: 


American Express (www.americanexpress.com) 
AOL (www.aol.com) 

Brodia (www.brodia.com) 

Compaq (www.compaq.com) 
CyberCash (www.cybercash.com) 
Discover (www.discovercard.com) 
FSTC (www.fstc.org) 

IBM (www.ibm.com) 

Mastercard (www.mastercard.com) 
Microsoft (www.microsoft.com) 
Novell (www.novell.com) 

SETCo (www.setco.org) 

Sun Microsystems (www.sun.com) 
Trintech (www.trintech.com) 
Visa (www.visa.com) 


The fields are derived from and consistent with the W3C P3P base data 
schema at 


<http://www.w3.org/TR/WD-P3P/basedata.html>. 
1.2 Relationship to Other Standards 
ECML Version 1 is not a replacement or alternative to SSL/TLS [RFC 
2246], SET [SET], XML [XML], or IOTP [IOTP]. These are important 
standards that provide functionality such as non-repudiatable 
transactions, automatable payment scheme selection, and smart card 


support. 


ECML may be used with any payment mechanism. It simply allows a 
merchant to publish consistent simple web forms. 


Multiple wallets and multiple merchants plan to interoperably support 
ECML. This is an open standard. ECML is designed to be simple. 
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Version 1 of the project adds no new technology to the web. A 
merchant can adopt ECML and gain the support of these multiple 
Wallets by making very simple changes to the HTML pages that they 
currently use to support their customers. Use of ECML requires no 
license. 


1.3 Areas Deferred to Future Versions 


Standardization of information fields transmitted from the merchant 
to the consumer, considerations for business purchasing cards, non- 
card payment mechanisms, wallet activation, privacy related 
mechanisms, additional payment mechanisms, and any sort of 
"negotiation" were among the areas deferred to consideration in 


future versions. Hidden or other special fields were minimized. The 
primary target was North American consumer to merchant electronic 
commerce. 


2. Using The Fields 


To conform to this document, the field names shall be as listed in 
section 3 below. Note: this does not impose any restriction on the 
user visible labeling of fields, just on their names as used in 
communication with the merchant. 


2.1 Presentation of the Fields 


There is no necessary implication as to the order or manner of 
presentation. Some merchants may wish to ask for more information, 
some less by omitting fields. Some merchants may ask for the 
information they want in one HTML form on one web page, others may 
ask for parts of the information at different times on different 
pages. For example, it is common to ask for "Ship to" information 
earlier, so shipping cost can be computed, before the payment method 
information. Some merchants may require that all the information 
they request be provided while other make much information optional, 
etc. 


There is no way with version 1 of ECML to indicate what fields the 
merchant considers mandatory. From the point of view of customer 
software, all fields are optional to complete. However, the merchant 
may give an error or re-present a request for information if some 
field it requires is not completed, just as it may if a field is 
completed in a manner it considers erroneous. 
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2.2 Methods and Flow of Setting the Fields 


There are a variety of methods of communication possible between the 
customer and the merchant by which the merchant can indicate what 
fields they want that the consumer can provide. Probably the easiest 
to use for currently deployed software is as fields in an HTML 
[HTML4.0] form. Other possibilities are to use the W3C P3P protocol 
or the IOTP Authenticate transaction [IOTP]. 


User action or the appearance of the Ecom_SchemaVersion field are 
examples of triggers that could be used to initiate a facility 
capable of filling in fields. It is required that the 
Ecom_SchemaVersion field, which is usually a hidden field, be 
included on every web page that has any "Ecom_" fields. 


Because web pages can load very slowly, it may not be clear to an 
automated field fill-in function when it is finished filling in 
fields on a web page. For this reason, it is recommended that the 
Ecom_SchemaVersion field be the last "Ecom_" field on a web page. 


Merchant requests for information can extend over several web pages. 
Without further provision, a facility could either require re- 
starting on each page or possibly violate or appear to violate 
privacy by continuing to fill in fields for pages beyond with end of 
the transaction with a particular merchant. For this reason the 
Ecom_TransactionComplete field, which is normally hidden, is 
provided. It is recommended that it appear on the last web page 
involved in a transaction, just before an Ecom_SchemaVersion field, 
so that multi-web-page automated field fill in logic could know when 
to stop if it chooses to check for this field. 
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2.3 HIML Example 
An example in HTML might be as follows: 


<HTML> 
<HEAD> 
<title> eCom Fields Example </title> 
</HEAD> 
<BODY> 
<FORM action="http://ecom.example.com" method="POST"> 
Please enter card information: 
<p>Your name on the card 
<INPUT type="text" name="Ecom_Payment_Card_Name" SIZE=40> 
<br>The card number 
<INPUT type="text" name="Ecom_Payment_Card_Number" SIZE=19> 
<br>Expiration date (MM YY) 
<INPUT type="text" name="Ecom_Payment_Card_ExpDate_Month" SIZE=2> 
<INPUT type="text" name="Ecom_Payment_Card_ExpDate_Year" SIZE=4> 
<INPUT type="hidden" name="Ecom_Payment_Card_Protocol"> 
<INPUT type="hidden" name="Ecom_SchemaVersion" 
value="http://www.ecml.org/version/1.0"> 
<br> 
<INPUT type="submit" value="sSubmit"> <INPUT type="reset"> 
</FORM> 
</BODY> 
</HTML> 


After all of the pages are submitted, the merchant will reply with a 
confirmation page informing both the user and the wallet that the 
transaction is complete. 


<HTML> 

<HEAD> 

<title> eCom Transaction Complete Example </title> 

</HEAD> 

<BODY> 

<FORM> 

Thank you for your order. It will be shipped in several days. 

<INPUT type="hidden" name="Ecom_TransactionComplete"> 

<INPUT type="hidden" name="Ecom_SchemaVersion" 
value="http://www.ecml.org/version/1.0"> 

</FORM> 

</BODY> 

</HTML> 
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The fields are listed below along with the minimum data entry size to 


allow. 


indicated by the embedded underscore 


Note that these fields are hierarchically organized as 


("_") characters. A 


ppropriate 


consumer to merchant transmission mechanisms may use this to request 


and send aggregates, 


such as Ecom_Payment_Card_ExpDate to encompass 


all the date components or Ecom_ShipTo to encompass all the ship to 


components that the consumer is willing to provide. 


The 


marshalling 


and unmarshalling of the components of such aggregates depends on the 
data transfer protocol used. 


IMPORTANT NOTE: 
ALLOW FOR ON DATA ENTRY. 
contents of the field and merchant software should, 
prepared to receive a longer or shorter value. 
areas where, 


"MIN" 


for example, 


It is NOT the minimum size for 
in mo 
Merchant 
the state/province name or phon 


in the table below is the MINIMUM DATA SIZE TO 


valid 

st cases, be 
dealing with 
e number is 


longer than the "Min" given below must obviously permit longer data 
entry. 


field. 


FIELD 


ship 
ship 
ship 
ship 
ship 
ship 
ship 
ship 
ship 
ship 
ship 
ship 
ship 
ship 


bill 
bill 
bill 
bill 
bill 
bill 
bill 
bill 
bill 


to 
to 
to 
to 
to 
to 
to 
to 
to 
to 
to 
to 
to 
to 


to 
to 
to 
to 
to 
to 
to 
to 
to 
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In some cases, 


title 

first name 
middle name 
last name 

name suffix 
street linel 
street line2 
street line3 
city 
state/province 
zip/postal code 
country 

phone 

email 


title 

first name 
middle name 
last name 
name suffix 
street linel 
street line2 
street line3 
city 


Goldstein 


however, 
sense and where this is the case, 


there is a maximum size t 
it is documented inawN 


NAME 


Ecom_ShipTo_Postal_Name_Prefix 
Ecom_ShipTo_Postal_Name_First 
Ecom_ShipTo_Postal_Name_Middle 
Ecom_ShipTo_Postal_Name_Last 
Ecom_ShipTo_Postal_Name_Suffix 
Ecom_ShipTo_Postal_Street_Linel 
Ecom_ShipTo_Postal_Street_Line2 
Ecom_ShipTo_Postal_Street_Line3 
Ecom_ShipTo_Postal_City 
Ecom_ShipTo_Postal_StateProv 
Ecom_ShipTo_Postal_PostalCode 
Ecom_ShipTo_Postal_CountryCode 
Ecom_ShipTo_Telecom_Phone_Number 
Ecom_ShipTo_Online_Email 


Ecom_BillTo_Postal_Name_Prefix 
Ecom_BillTo_Postal_Name_First 
Ecom_BillTo_Postal_Name_Middle 
Ecom_BillTo_Postal_Name_Last 
Ecom_BillTo_Postal_Name_Suffix 
Ecom_BillTo_Postal_Street_Linel 
Ecom_BillTo_Postal_Street_Line2 
Ecom_BillTo_Postal_Street_Line3 
Ecom_BillTo_Postal_City 
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bill to state/province Ecom_BillTo_Postal_StateProv 2 (5) 
bill to zip/postal code Ecom_BillTo_Postal_PostalCode 14 ( 6) 
bill to country Ecom BillTo_Postal_CountryCode 2 ( 7) 
bill to phone Ecom_BillTo_Telecom_Phone_Number 10 ( 8) 
bill to email Ecom_BillTo_Online_Email 40 ( 9) 
receiptTo title Ecom_ReceiptTo_Postal_Name_Prefix 4 ( 1) 
receiptTo first name Ecom_ReceiptTo_Postal_Name_First 15 
receiptTo middle name Ecom_ReceiptTo_Postal_Name_Middle 15 ( 2) 
receiptTo last name Ecom_ReceiptTo_Postal_Name_Last 15 
receiptTo name suffix Ecom_ReceiptTo_Postal_Name_Suffix 4 ( 3) 
receiptTo street linel Ecom_ReceiptTo_Postal_Street_Linel 20 ( 4) 
receiptTo street line2 Ecom_ReceiptTo_Postal_Street_Line2 20 ( 4) 
receiptTo street line3 Ecom_ReceiptTo_Postal_Street_Line3 20 ( 4) 
receiptTo city Ecom_ReceiptTo_Postal_City 22 
receiptTo state/province Ecom_ReceiptTo_Postal_StateProv 2 (5) 
receiptTo postal code Ecom_ReceiptTo_Postal_PostalCode 14 ( 6) 
receiptTo country Ecom_ReceiptTo_Postal_CountryCode 2 (7) 
receiptTo phone Ecom_ReceiptTo_Telecom_Phone_Number 10 ( 8) 
receiptTo email Ecom_ReceiptTo_Online_Email 40 ( 9) 
name on card Ecom_Payment_Card_Name 30 (10) 
card type Ecom_Payment_Card_Type 4 (11) 
card number Ecom_Payment_Card_Number 19 (12) 
card verification value Ecom_Payment_Card_Verification 4 (13) 
card expire date day Ecom_Payment_Card_ExpDate_Day 2 (14) 
card expire date month Ecom_Payment_Card_ExpDate_Month 2 (15) 
card expire date year Ecom_Payment_Card_ExpDate_Year 4 (16) 
card protocols Ecom_Payment_Card_Protocol 20 (17) 
consumer order ID Ecom_ConsumerOrderID 20 (18) 
schema version Ecom_SchemaVersion 30 (19) 
end transaction flag Ecom_TransactionComplete - (20) 
FIELD NAME Min Notes 


IMPORTANT NOTE: "MIN" in the table above is the MINIMUM DATA SIZE TO 
ALLOW FOR ON DATA ENTRY. It is NOT the minimum size for valid 
contents of the field and merchant software should, in most cases, be 
prepared to receive a longer or shorter value. Merchant dealing with 
areas where, for example, the state/province name or phone number is 
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longer than the "Min" given below must obviously permit longer data 
entry. In some cases, however, there is a maximum size that makes 
sense and this is documented in a Note for the field. 

4. End Notes 


( 1) For example: Mr., Mrs., Ms., Dr. This field is commonly not 
used. 


( 2) May also be used for middle initial 


( 3) For example: Ph.D., Jr. (Junior), 3rd, Esq. (Esquire). This 
field is commonly not used. 


( 4) Address lines must be filled in the order linel, then line2, 
last line3. 


( 5) 2 characters are the minimum for the US and Canada, other 
countries may require longer fields. For the US use 2 character 
US Postal state abbreviation. 


( 6) Minimum field lengths for Postal Code will vary based on 
international market served. Use 5 character or 5+4 ZIP for the 
US and 6 character postal code for Canada. The size given, 14, 
is believed to be the maximum required anywhere in the world. 


( 7) Use [ISO 3166] standard two letter codes 
<http://www.din.de/gremien/nas/nabd/iso3166ma/codlstpl.html> for 
country names. 


( 8) 10 digits are the minimum for numbers local to the North 
American Numbering Plan (<http://www.nanpa.com>: US, Canada and 
a number of smaller Caribbean and Pacific nations (but not 
Cuba)), other countries may require longer fields. Telephone 
numbers are complicated by differing international access codes, 
variant punctuation of area/city codes within countries, 
confusion caused by the fact that the international access code 
in the NANP region is usually the same as the "country code" for 
that area (1), etc. It will probably be necessary to use 
heuristics or human examination based on the telephone number 
and addresses given to figure out how to actually call a 
customer. It is recommend that an "x" be placed before extension 
numbers. 


( 9) For example: Jsmith@example.com 


(10) The name of the cardholder. 
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(11) Use the first 4 letters of the association name: American 
Express=AMER; Diners Club=DINE; Discover=DISC; JCB=JCB; 
Mastercard=MAST; Visa=VISA. 


(12) Includes the check digit at end but no spaces or hyphens [ISO 
7812]. The Min given, 19, is the longest number permitted under 
the ISO standard. 


(13) An additional cardholder verification number printed on the card 
(but not embossed or recorded on the magnetic stripe) such as 
American Express’ CIV, MasterCard’s CVC2, and Visa’s CVV2 
values. 


(14) The day of the month. Values: 1-31 


(15) The month of the year. Jan - 1, Feb - 2, March - 3, etc.; 
Values: 1-12 


(16) The value in the wallet cell is always four digits, e.g., 1999, 
2000, 2001, 


(17) A space separated list of protocols available in connection with 
the specified card. Initial list of case insensitive tokens: 
none, set, & setcert. "Set" indicates usable with SET protocol 
(i.e., is in a SET wallet) but does not have a SET certificate. 
"Setcert" indicates same but does have a set certificate. 

"None" indicates that automatic field fill is operating but 
there is no SET wallet or the card is not entered in any SET 
wallet. 


(18) A unique order ID generated by the consumer software. 


(19) URI indicating version of this set of fields. Usually a hidden 
field. Equal to "http://www.ecml.org/version/1.0" for this 
version. 


(20) A flag to indicate that this web-page/aggregate is the final one 
for this transaction. Usually a hidden field. 


5. Security Considerations 


The information called for by many of these fields is sensitive and 
should be protected if being sent over the public Internet or through 
other channels where it can be observed. Mechanisms for such 
protection are not specified herein but channel encryption such as 
SSL/TLS [RFC 2246] or IPSec [RFC 2411] would be appropriate in many 
cases. 
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User control over release of such information is needed to protect 
the user’s privacy. 


Any multi-web-page or other multi-aggregate field fill in or data 
provision mechanism should check for the Ecom_TransactionComplete 
field and cease automated fill when it is encountered until fill is 
further authorized. 
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Full Copyright Statement 
Copyright (C) The Internet Society (1999). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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